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FOREWORD 


This  report  is  a  portion  of  the  documentation  of  Release  4.0  of  the 
Highway  Information  System  undertaken  by  the  Department  of  Civil  Engineering 
and  Engineering  Mechanics,  Montana  State  University.   The  retrieval  system 
has  been  evolving  over  the  last  several  years  under  the  sponsorship  of  the 
Planning  and  Research  Bureau  of  the  Montana  Department  of  Highways  with  some 
assistance  from  the  Highway  Traffic  Safety  Division,  Montana  Department  of 
Community  Affairs. 

Release  4.0  of  the  Highway  Information  System  is  documented  in  the 
following  volumes: 

Highway  Information  System  Release  4.0:   System  Overview 

Provides  an  introduction  to  the  Highway  Information  System. 

Highway  Information  System  Release  4.0:   Index 

Provides  an  index  to  all  manuals  except  the  System  Overview 
and  Program  Listings. 

Highway  Information  System  Release  4.0:   User's  Manual 

Describes  how  to  use  the  Highway  Information  System  for  re- 
trieving information  and  for  printing  reports  and  summaries. 

Highway  Information  System  Release  4.0:   Data  Coding  Manual 

Describes  the  data  card  formats  for  entering  data  into  the 
Highway  Information  System  files. 

Highway  Information  System  Release  4.0:   System  Maintenance  Manual 

Provides  information  for  performing  scheduled  system  backups  and 
file  reorganizations  and  for  allocating  system  files. 

Highway  Information  System  Release  4.0:   Record  Formats  &  Subroutines 

Describes  the  internal  record  formats  of  the  various  files  and 
provides  calling  sequences  to  subroutines.   This  manual  is  in- 
tended for  persons  writing  new  programs  to  add  to  the  Highway 
Information  System. 

Highway  Information  System  Release  4.0:   Programming  Details 

Describes  the  existing  programs  and  provides  a  guide  to  the 
program  listings.   This  manual  is  intended  for  persons  main- 
taining existing  software  in  the  Highway  Information  System. 

Highway  Information  System  Release  4.0:   Program  Listings 

Contains  computer-generated  listings  of  all  source  programs 
of  the  Highway  Information  System. 


Although  the  project  was  conceived,  initiated,  and  primarily  funded 
through  the  Planning  and  Research  Bureau  of  the  Montana  Department  of 
Highways,  the  development  cost  of  selected  portions  of  the  system  was  borne 
by  the  Highway  Traffic  Safety  Division  of  the  Montana  Department  of  Com- 
munity Affairs. 

In  developing  the  system,  the  CE  &  EM  Department  has  had  the  privilege 
of  using  an  IBM  0S/VS1  370/145  computer  located  at  the  Data  Processing 
Bureau  of  the  Montana  Department  of  Highways  in  Helena.   PL/I  has  been  used 
for  most  of  the  programs  because  of  its  versatility  and  ease  of  use.   BAL 
(assembler)  has  been  used  for  most  input-output  modules  and  for  other 
modules  that  require  its  increased  capabilities  and  efficiency  over  PL/I. 

The  project  could  never  have  progressed  to  its  current  state  without 
the  continued  and  patient  encouragement  and  assistance  from  the  Planning 
and  Research  Bureau  and  the  Data  Processing  Bureau  of  the  Montana  Department 
of  Highways,  and  from  the  Highway  Traffic  Safety  Division  of  the  Department 
of  Community  Affairs. 

The  project  conclusion  was  also  hastened  by  the  significant  effort  of 
other  project  personnel:   Scott  H.  Danforth,  R.  Helene  Knowlton,  and  Doug  M. 
Geiger . 
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CHAPTER  1 
INTRODUCTION 

Montana's  Highway  Information  System  (HIS)  is  a  computerized,  integrated 
file  system  consisting  of  a  large  number  of  separate  but  related  data  files 
and  a  sophisticated  set  of  specially  written  computer  programs  (software)  for 
accessing  those  files.   The  design  characteristics  of  this  system  are  discussed 
in  Chapter  2. 

Some  of  the  major  types  of  data  contained  in  the  system  include  roadway 
characteristics,  traffic  volumes,  traffic  accident  data,  railroad  crossing 
information,  bridge  information,  and  skid  test  results.   Each  of  these  types 
of  data  plus  some  additional  ones  are  elaborated  on  in  Chapter  3. 

Depending  upon  the  location  of  the  feature  or  event  in  question,  one  of 
three  different  location  methods  is  used.   The  primary  method  is  a  reference 
posting  system  which  Montana  calls  a  "true  mileage"  system.   All  three  of 
these  methods  are  discussed  in  Chapter  4. 

There  are  always  improvements  that  can  be  made  in  any  system,  and  that  is 
the  case  for  this  system  as  well.   These  potential  improvements  primarily  con- 
sist of  addition  of  new  data,  refinements  of  existing  analysis  techniques,  and 
provision  of  brand  new  analysis  techniques.   Some  such  improvements  which  could 
be  made  in  HIS  are  enumerated  in  Chapter  5. 

The  final  chapter  in  this  Overview  volume,  Chapter  6,  discusses  both  the 
availability  of  the  HIS  software  and  the  availability  of  more  detailed  HIS 
documentation. 

Historical  Background 

HIS  was  conceived  in  1969  when  the  Department  of  Highways  gave  Montana 
State  University  (the  University)  a  HP&R  contract  to  begin  software  development. 
That  first  contract  was  followed  by  additional  Department  of  Highways  contracts 
and  by  contracts  with  the  Highway  Traffic  Safety  Division  of  the  Department  of 
Community  Affairs,  the  office  of  the  Governor's  Representative  for  Highway 
Safety.   HIS  was  not  developed  overnight,  but  rather  individual  subsystems  were 
developed  as  either  opportunity  or  necessity  presented  itself. 

The  complete  set  of  documentation  of  which  this  Overview  Manual  is  a  part 
constitutes  the  final  product  of  the  most  recent  Department  of  Highways  contract 
with  the  University.   The  primary  task  performed  during  this  last  contract  has 
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been  the  insertion  of  fairly  generalized  data  selection  capabilities  into  much 
of  the  HIS  software.   To  differentiate  this  latest  set  of  HIS  software  from  its 
predecessors,  this  latest  set  is  referred  to  as  Release  4.0  of  HIS. 

Although  originally  justified  solely  on  the  basis  of  time  and  cost  savings 
in  generating  on-going  reports,  even  then  it  was  realized  that  the  most  notable 
long  term  benefits  would  occur  in  the  provision  of  general  inquiry  capabilities 
(data  selection  and  data  analysis) .   The  University  and  the  State  have  partic- 
ipated jointly  in  the  conceptual  development  of  the  system.   Over  90%  of  the 
software  composing  HIS  has  been  written  by  the  University  under  contract  to  the 
State.   The  remainder  has  been  written  by  the  Department  of  Highways  Data 
Processing  Bureau. 

Computer  Details 

The  system  is  housed  on  the  Department  of  Highways  IBM  OS/VSl  370/145 
computer  in  Helena.   It  is  written  in  a  combination  of  PL/I  and  Basic  Assembly 
Language  (BAL) .   Most  of  the  software  is  in  PL/I,  but  BAL  has  been  used  for  most 
input-output  modules  and  for  other  modules  requiring  its  flexibility  and  effi- 
ciency. 

The  software  consists  of  a  supervisory  module  (which  runs  under  the  control 
of  IBM's  OS),  many  application  modules,  and  a  large  number  of  common  routines 
shared  by  two  or  more  application  modules.   As  a  consequence  of  the  system  de- 
sign philosophy  discussed  in  the  next  chapter,  all  data  files,  even  those  which 
are  usually  read  sequentially,  are  of  necessity  stored  on  direct  access  devices. 
ISAM  is  used  extensively. 
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CHAPTER  2 
SYSTEM  DESIGN  CHARACTERISTICS 

Perhaps  the  strength  of  HIS  is  that  it  has  good,  high  design  standards. 
Although  there  are  a  few  unfortunate'  exceptions,  these  standards  have  usually 
been  met.   Some  of  these  system  design  characteristics  or  standards  are  dis- 
cussed below. 

User  Orientation 

This  is  undoubtedly  the  greatest  single  strength  of  HIS.   From  the  very 
beginning,  a  conscientious  effort  has  been  made  to  develop  a  system  which  tech- 
nicians and  others  possessing  negligible  computer  knowledge  can  easily  use. 
This  effort  has  been  pointed  in  two  different  directions. 

All  input  data  are  subjected  to  extensive  data  validity  checking  or  edit- 
ing.  When  data  fail  those  edits,  descriptive  and  documented  error  messages  are 
printed. 

Even  more  significant,  all  system  actions  are  initiated  by  an  English 
language  type  command  whose  structure  is  easy  to  learn  and  use.   Further,  cata- 
loged procedures  are  used  to  greatly  minimize  the  number  and  complexity  of  the 
system  control  cards  (Job  Control  Language  or  JCL)  which  the  user  must  furnish. 

As  an  example  of  the  user  orientation,  assume  that  you  want  to  summarize 
by  day  of  the  week  and  by  time  of  day  those  traffic  accidents  which  occurred 
during  the  first  two  months  of  1976  in  Gallatin  County.   Since  HIS  has  an  ex- 
isting program  for  generating  such  a  summary,  the  five  cards  shown  below  will 
accomplish  the  desired  task  (the  COUNTY,  START-DATE,  and  END-DATE  parameters 
could  occur  in  any  sequence) : 

//     JOB    necessary  accounting  information 

//      EXEC  HISACC 

//SYSIN   DD  * 

: SUM-BY-DAY- &-TIME, COUNTY=GALLATIN, START-DATE=01/01/76 , END-DATE=02/29/76 

/* 
Root  Data 

Original,  raw,  unmanipulated  data  are  used  almost  exclusively.   This  mini- 
mizes the  chance  of  errors  in  the  input  data  and  gives  the  maximum  possible 
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flexibility  in  that  the  computer  can  assimilate  the  data  in  a  large  variety  of 
ways.   It  also  reduces  data  preparation  costs. 

The  biggest  violation  of  this  standard  occurs  in  the  traffic  file.   Man- 
ually computed  AADT' s  rather  than  unfactored  field  counts  are  used  to  create 
that  file.   This  exception  was  made  early  in  the  development  of  HIS  due  to  the 
demands  for  expediency.   However,  the  State  has  never  elected  to  go  back  and 
alter  that  approach. 

Data  Integrity 

Data  integrity  refers  to  the  highly  desirable  situation  wherein  only  ac- 
curate, complete,  up  to  date,  internally  consistent  data  are  included  in  the 
data  base.   To  paraphrase  an  old  adage,  if  there  is  garbage  in  the  data  base, 
the  output  of  the  system  will  be  garbage. 

HIS  attempts  to  achieve  data  integrity  in  a  variety  of  ways :   extensive 
editing  is  done  on  data  entry,  no  data  elements  are  duplicated  between  or  within 
data  files,  and  the  data  already  in  the  system  are  subjected  to  continual  scru- 
tiny.  Another  important  ingredient  for  data  integrity  is  to  have  one  individual 
rather  than  a  group  of  individuals  responsible  for  maintaining  specified  data 
elements. 

Data  Security 

Data  security  refers  to  the  protection  of  the  data  base  from  natural  or 
man-caused  destruction,  alteration,  or  unauthorized  use.  In  the  case  of  de- 
struction or  alteration,  it  includes  the  recovery  from  such  a  situation. 

Some  data  security  provisions  have  been  incorporated  into  HIS.   For  ex- 
ample, individual  "programs"  such  as  those  used  to  update  or  modify  a  data  file 
can  be  password  protected  to  prevent  unauthorized  use. 

Another  aspect  of  data  security  is  periodically  making  backup  copies  of  the 
data  files  and  storing  those  backup  copies  in  a  safe  location.   HIS  includes 
software  for  making  such  backup  copies  and  for  restoring  the  data  files  from 
those  tapes. 
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Direct  Access 

All  HIS  data  files  are  maintained  on  direct  access  devices  (discs  as  con- 
trasted to  computer  tapes) .   HIS  gets  much  of  its  power  through  the  use  of 
direct  access  input-output,  and  the  whole  system  is  tied  to  that  methodology. 

This  methodology  speeds  data  access,  permits  "simultaneous"  access  of  a 
single  data  file  by  several  users,  simplifies  data  management  (updating 
records) ,  reduces  operator  intervention,  and  facilitates  future  conversion 
to  an  on-line  system. 

On-Line  Potential 


An  on-line  system  is  one  in  which  file  updates,  analysis  runs,  etc.,  are 
performed  in  a  dialogue  fashion  almost  at  the  very  instant  the  commands  are 
submitted  by  a  user  sitting  at  a  computer  terminal. 

HIS  is  not  an  on-line  system.   However,  it  has  been  designed  such  that 
it  could  be  converted  from  a  batch  system  to  an  on-line  system  either  in  total 
or  in  part  with  as  minimal  effort  as  possible. 

Even  the  current  system  can  approach  the  characteristics  of  an  on-line 
system  through  the  process  of  submitting  batch  jobs  from  a  computer  terminal. 
The  University  has  followed  this  procedure  in  its  software  development  efforts 
with  great  success  thus  easily  overcoming  the  80  miles  separating  Bozeman  and 
Helena. 
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CHAPTER  3 
SUBSYSTEMS 

HIS  consists  of  an  ever  increasing  number  of  subsystems.   Each  subsystem  is 
comprised  of  one  or  sometimes  more  data  files  and  a  corresponding  set  of  soft- 
ware.  In  spite  of  the  fact  that  some  applications  will  use  software  and  data 
exclusively  from  one  subsystem,  these  subsystems  are  not  independent;  they  are 
interrelated. 

Typically,  each  subsystem  includes  software  for  report  generation,  general 
inquiry,  and  data  management.   Report  generation  capabilities  consist  of  the 
generation  of  programmed,  predefined  listings  and  summaries. 

The  general  inquiry  software  usually  includes  data  selection  capabilities 
and  data  analysis  capabilities.   The  data  selection  provisions  implemented  in 
the  system  consist  of  the  capability  of  selecting  or  limiting  the  input  data 
used  in  generating  one  of  the  predefined  reports,  summaries  or  analyses.   Data 
analysis  refers  to  a  more  sophisticated  use  of  data  normally  incorporating  some 
decision  making  capability.   An  example  would  be  the  accident  clusters  program 
which  identifies  groups  or  clusters  of  accidents  along  a  route. 

Data  management  software  exists  to  create  files,  update  and  edit  those 
files,  make  backup  copies  of  those  files,  and  restore  files  from  backup  copies. 

The  primary  subsystems  are  briefly  discussed  in  the  remainder  of  this 
chapter.   Not  discussed  are  such  subsystems    i 

as  the  rural  sign  inventory,  urban  sign  inventory,  and  emergency  medical  tech- 
nician subsystems. 

Road log 

The  roadlog  file  contains  such  information  as  system  (Interstate,  FAP ,  FAS, 
FAU,  etc.),  route  number,  milepoint,  section  length,  verbal  description,  admin- 
istrative information,  jurisdictional  information,  year  built,  year  improved, 
number  of  lanes,  width,  and  surface  and  base  materials. 

In  conjunction  with  the  true  mileage  file,  this  file  is  the  basic  building 
block  of  the  entire  system. 
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True  Mileage 

As  discussed  in  the  next  chapter,  the  basic  location  method  used  outside  of 
urban  areas  is  a  reference  posting  system.   The  true  mileage  file  contains  the 
true  or  actual  distance  from  the  beginning  of  a  route  to  each  reference  post 
along  the  route.   This  permits  the  computer  to  convert  any  milepoint  (a  location 
identification  coded  in  true  mileage  format)  to  the  actual  distance  from  the 
beginning  of  the  route. 

Traffic 

The  traffic  file  contains  such  information  as  design  hour  volume  and,  for 
each  of  the  past  three  years,  AADT,  percent  out-of-state  vehicles,  percent 
pickups,  and  percent  commercial  vehicles. 

Sufficiency 

Montana  uses  a  sufficiency  rating  methodology  for  allocating  FAP  construc- 
tion funds  to  the  various  financial  districts.   The  necessary  computations  are 
performed  by  the  HIS  sufficiency  software  using  data  in  the  sufficiency  file. 
These  data  include  design  and  average  speeds,  terrain  classification,  sight 
restriction  information,  geometric  constraints,  and  road  condition  ratings. 

Accident 

The  Montana  Highway  Patrol  uses  HIS  accident  subsystem  data  management 
software  for  creating  and  maintaining  the  HIS  traffic  accident  data  files. 
These  accident  files  are  used  directly  by  three  different  state  agencies  and 
indirectly  by  other  state  agencies.   In  addition,  several  local  governmental 
agencies  use  these  files  by  going  through  one  of  the  three  state  agencies  men- 
tioned previously. 

Software  capabilities  include  the  generation  of  many  different  summaries 
including  the  National  Safety  Council  Form  16  summary,  the  generation  of  an 
accident-by-sections  report  to  identify  those  highway  sections  having  accident 
rates  in  excess  of  a  statistically  computed  critical  limit,  the  identification 
of  those  urban  intersections  having  a  large  number  of  accidents,  and  the  iden- 
tification of  groups  or  clusters  of  rural  accidents.   The  Department  of  High- 
ways uses  the  clusters  program  for  identifying  potential  locations  for  safety 
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improvements,  and  the  Highway  Patrol  uses  it  for  determining  where  to  concen- 
trate their  selective  law  enforcement  efforts. 

Railroad  Crossing 

The  railroad  crossing  file  contains  railroad/track/train  information,  sight 
distance  information,  and  protection  information.  It  permits  the  identification 
of  high  hazard  crossings. 

Bridge 

This  file  includes  design  data,  clearance  information,  and  condition  infor- 
mation.  Several  different  reports  are  generated  by  this  subsystem,  some  of 
which  are  required  by  the  federal  government. 

Skid  Test 

Montana,  as  well  as  other  states,  has  a  skid  test  vehicle  which  they  use 
both  for  the  routine  collection  of  pavement  skid  test  inventory  data  and  for 
special  studies.   Appropriate  data  from  all  such  tests  are  incorporated  into  the 
skid  test  file. 
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CHAPTER  4 
LOCATION  METHODS 

There  are  currently  three  different  location  methods  implemented  within 
HIS:   rural  milepoint,  rural  non-milepoint,  and  coordinates.   A  given  location 
or  event  is  coded  to  one  of  these  three  methods.   There  is  no  freedom  of  choice 
in  the  decision;  it  is  dictated  by  the  particular  combination  of  such  factors  as 
(1)  whether  the  route  in  question  is  inside  or  outside  the  city  limits,  and  (2) 
whether  the  route  has  been  assigned  milepoints.   In  addition  to  those  three 
methods,  it  is  sometimes  permissible  to  fail  to  code  precise  location  informa- 
tion on  certain  events  such  as  some  accidents. 

Rural  Milepointed 

This  method  is  currently  used  for  all  rural,  on  Federal-Aid  system  loca- 
tions.  Conceptually,  it  could  be  used  (and  is  used  in  some  cases)  for  any 
route,  rural  or  urban,  that  is  assigned  milepoints,  regardless  of  whether  or  not 
reference  posts  have  actually  been  placed  in  the  field. 

Frequently  referred  to  in  Montana  as  the  true  mileage  concept,  this  system 
is  actually  a  reference  post  system  which  has  the  external  appearance  of  a  mile 
post  system.   Routes  start  at  reference  post  (RP)  0  and  reference  posts  are 
numbered  consecutively  to  the  end  of  the  route.   However,  there  is  no  require- 
ment that  consecutive  reference  posts  be  located  exactly  a  mile  apart.   Some  are 
a  few  thousandths  of  a  mile  apart;  others  are  over  four  miles  apart.   Most, 
however,  are  close  to  if  not  exactly  a  mile  apart. 

An  example  of  a  true  mileage  format  milepoint  would  be : 

132+0.920 

This  is  interpreted  as  a  location  0.920  miles  away  from  RP  132.   Since  the  sign 
is  plus,  we  are  0.920  miles  "beyond"  RP  132  (closer  to  the  end  of  the  route). 

Look  at  the  below  diagram.   Among  other  possibilities,  the  milepoint  of 
Point  A  could  be  coded  as  150+1.500,  151+0.700,  152-0.600,  or  153-1.700.   Re- 
gardless of  how  the  milepoint  was  coded,  the  software  would  consult  the  true 
mileage  file  and  actually  use  a  milepoint  of  151+0.700.   If  the  record  is  being 
inserted  in  a  data  file,  the  milepoint  of  that  record  in  the  data  file  would  be 
151+0.700. 


4-1 


0.8  miles  0.7  miles  0.6   miles  1.1  miles 


-*r 


CN 

LO 

Eh 

H 

2 

H 

a 

O 

<  m 

o  .H 

in  m  E-" 

r-\  M  2 

M 

c^  Pj  o 

«  «  ft 

Given  any  milepoint,  HIS  can  compute  the  true  mileage  of  that  point  from 
the  beginning  of  the  route  by  consulting  the  true  mileage  file.  Thus,  in  the 
above  diagram,  HIS  can  easily  compute  the  distance  from  Point  A  to  Point  B  by 
first  computing  the  true  mileage  of  those  two  points  and  then  subtracting  one 
from  the  other. 

These  computations  are  very  simple  and  are  quickly  performed  by  the  com- 
puter.  Since  the  system  is  basically  a  reference  post  system,  it  provides  a 
great  deal  of  flexibility  while  still  having  the  ability  to  easily  relate  one 
point  to  another.   For  example,  there  is  no  need  to  place  a  reference  post  in 
the  center  of  an  intersection,  on  a  bridge,  or  in  a  tunnel. 

Even  more  important,  route  adjustments  can  be  made  with  no  impact  on  pre- 
viously coded  milepoints  on  unaltered  portions  of  the  route  and  minimal  if  any 
impact  on  previously  coded  milepoints  in  the  immediate  vicinity  of  the  change. 

Rural  Non-Milepointed 

A  separate  location  method  is  used  for  accidents  occurring  in  rural  areas 
on  non-milepointed  routes  (which  usually  means  on  non  Federal-Aid  routes).  It 
consists  of  coding  the  section,  township,  range,  and  one  digit  x  and  y  coordi- 
nates within  the  section. 

The  system  has  negligible  capabilities  for  data  coded  with  this  method. 

Coordinates 

Each  of  Montana's  126  cities  has  a  coordinate  system  assigned  to  it.   Skid 
tests,  accidents,  etc. ,  occurring  within  one  of  these  cities  are  either  assigned 
appropriate  x  and  y  coordintes  or  else  entered  into  the  system  without  specific 
location  information.   It  is  expected  that  all  locations  on  Federal-Aid  routes 
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will  be  assigned  coordinates.  If  furnished  with  a  grid  table  consisting  of 
intersection  coordinates,  the  accident  subsystem  can  identify  high  accident 
intersections  by  examining  the  assigned  coordinates  of  individual  accidents. 

A  variation  of  the  coordinate  method  is  used  in  the  urban  sign  inventory 
subsystem.  Other  variations  are  being  considered  in  order  to  achieve  maximum 
usability  of  the  basic  data.   Eventually,  each  street  may  be  milepointed. 
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CHAPTER  5 
POSSIBLE  IMPROVEMENTS 

Regardless  of  how  good  a  system  is,  it  can  always  be  improved.   New  capa- 
bilities could  be  added  and  existing  capabilities  improved.   Some  such  improve- 
ments which  could  be  made  to  HIS  are  discussed  in  this  chapter. 

The  system  currently  lacks  both  horizontal  and  vertical  alignment  data.   If 
a  geometries  file  were  created,  it  would  be  possible  to  incorporate  geometric 
data  into  accident  analysis  procedures  and  even  to  produce  computer  generated 
plots. 

The  traffic  subsystem  should  be  revised  to  get  back  to  or  at  least  approach 
the  design  philosophy  of  inputting  only  raw  data.   The  current  use  of  manually 
computed  AADT' s  restricts  the  flexibility  of  the  file  and  results  in  too  long  a 
time  delay  before  new  data  are  available  in  the  system. 

Currently,  the  roadlog  and  various  other  files  contain  the  "as  of  today" 
data.   If  one  wishes  the  data  corresponding  to  the  physical  situation  as  of  two 
years  ago,  it  is  necessary  to  restore  the  backup  copies  of  the  outdated  files 
that  hopefully  correspond  to  that  point  in  time.   It  would  not  be  easy,  but  the 
files  and  software  could  be  restructured  to  maintain  historical  data  in  the 
current  files.   This  would  greatly  simplify  performing  many  types  of  before  and 
after  studies. 

Separate  or  split  alignments  currently  have  to  be  treated  as  a  single 
divided  alignment.   Similarly,  the  existing  system  cannot  adequately  handle 
ramps.   With  a  little  thought  and  effort,  the  software  could  be  revised  to 
handle  those  situations. 

A  number  of  other  things  could  be  done  to  improve  HIS.   Certain  analysis 
procedures  need  further  refinement,  maintenance  data  could  be  added,  and  certain 
software  modules  (primarily  the  older  ones)  could  be  made  more  efficient  and 
less  dependent  upon  such  uniquely  Montana  characteristics  as  56  counties  and  126 
cities. 
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CHAPTER  6 

AVAILABILITY  OF  SOFTWARE  AND  ADDITIONAL 
DOCUMENTATION 


HIS  is  in  the  public  domain  and  hence  both  the  software  and  more  detailed 
documentation  are  available  upon  request  to  the  Chief,  Planning  and  Research 
Bureau,  Montana  Department  of  Highways,  Helena,  Montana  59601.   An  appropriate 
charge  might  be  made  by  the  Department  of  Highways  to  recover  their  direct 
costs  in  fulfilling  a  request. 

Software 

HIS  is  a  complex  set  of  software  comprising  some  70,000  PL/I  and  basic 
assembly  language  source  statements.   It  will  only  run  on  an  IBM  360/370 
computer  and  only  under  the  OS  operating  system.   Due  to  the  interrelations 
of  both  the  software  and  the  data  files,  it  is  virtually  impossible  to  isolate 
one  particular  subsystem  or  one  particular  program  and  attempt  to  implement  it 
by  itself. 

Some  of  the  software,  particularly  the  older  software,  is  very  closely 
tied  to  such  things  as  given  card  formats,  given  data  element  codes,  56  counties, 
126  cities,  all  urban  areas  self-contained  within  a  single  county,  no  cities 
"embedded"  within  other  cities,  etc.   Although  software  modifications  were 
nearing  completion,  the  Utah  Department  of  Highways  has  abandoned  a  brief  effort 
to  implement  HIS  in  their  state.   They  were  attempting  to  make  the  minimal  possible 
software  changes  and  to  basically  adopt  Montana  card  formats  and  data  element 
codes. 

The  Minnesota  Department  of  Highways  has  decided  to  adopt  a  significantly 
modified  version  of  HIS  designed  for  their  data  and  for  their  analysis  require- 
ments.  To  aid  them  in  this  work,  they  recently  signed  a  long  term  contract  with 
Montana  State  University.   The  University  will  be  assisting  them  with  system 
conception  and  will  perform  the  vast  majority  of  the  software  modifications. 

Additional  Documentation 

Including  this  volume,  Release  4.0  of  HIS  is  documented  in  a  total  of  eight 
volumes,  two  of  which  are  so  lengthy  that  they  have  been  divided  into  several 
parts.   Even  excluding  the  program  listings,  these  volumes  make  a  very  impressive 
stack.   The  specific  volume  titles  and  a  brief  description  of  their  individual 
contents  can  be  found  in  the  FOREWORD  of  each  volume  (including  this  volume) . 
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